An ITMS-91061: Missing privacy manifest rejection email looks as follows: ITMS-91061: Missing privacy manifest- Your app includes "<path/to/SDK>", which includes , an SDK that was identified in the documentation as a privacy-impacting third-party SDK. Starting February 12, 2025, if a new app includes a privacy-impacting SDK, or an app update adds a new privacy-impacting SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements. Glossary ITMS-91061: Missing privacy manifest: An email that includes the name and path of privacy-impacting SDK(s) with no privacy manifest files in your app bundle. For more information, see https://developer.apple.com/support/third-party-SDK-requirements. : The specified privacy-impacting SDK that doesn't include a privacy manifest file. If you are the developer of the rejected app, gather the name of the SDK from the email you received from Apple, then contact the SDK's provider for an updated version that includes a valid privacy manifest. After receiving an updated version of the SDK, verify the SDK includes a valid privacy manifest file at the expected location. For more information, see Adding a privacy manifest to your app or third-party SDK. If your app includes a privacy manifest file, make sure the file only describes the privacy practices of your app. Do not add the privacy practices of the SDK to your app's privacy manifest. If the email lists multiple SDKs, repeat the above process for all of them. If you are the developer of an SDK listed in the email, publish an updated version of your SDK that includes a privacy manifest file with valid keys and values. Every privacy-impacting SDK must contain a privacy manifest file that only describes its privacy practices. To learn how to add a valid privacy manifest to your SDK, see the Additional resources section below. Additional resources Privacy manifest files Describing data use in privacy manifests Describing use of required reason API Adding a privacy manifest to your app or third-party SDK TN3182: Adding privacy tracking keys to your privacy manifest TN3183: Adding required reason API entries to your privacy manifest TN3184: Adding data collection details to your privacy manifest TN3181: Debugging an invalid privacy manifest

In this post, we'll share tips to help you submit apps that deliver original ideas to your users. When working on your app, focus on creating interesting, unique experiences that aren't already available. Apps that actively try to copy other apps won't pass review, and accounts that repeatedly submit copycat apps or attempt to impersonate a service will be closed. The rules that prevent copycat and impersonator apps from being distributed on the App Store are described in App Review Guideline 4.1: 4.1 Copycats (a) Come up with your own ideas. We know you have them, so make yours come to life. Don’t simply copy the latest popular app on the App Store, or make some minor changes to another app’s name or UI and pass it off as your own. In addition to risking an intellectual property infringement claim, it makes the App Store harder to navigate and just isn’t fair to your fellow developers. (b) Submitting apps which impersonate other apps or services is considered a violation of the Developer Code of Conduct and may result in removal from the Apple Developer Program.(c) You cannot use another developer’s icon, brand, or product name in your app’s icon or name, without approval from the developer. These requirements help make the App Store both a safe place for people to discover apps and a platform for all developers to be successful. Best Practices Here are three best practices that will help you submit apps that follow App Review Guideline 4.1: 1. Submit apps with unique content and features. People want apps that provide unique experiences. Find areas that aren't currently being served and build compelling apps for those audiences. Do: Create apps that provide a new experience or a unique spin on an existing concept. Design original, delightful interfaces that elegantly meet your user's needs. Don't: Don’t imitate the features and functionality of other apps. Don’t copy the look and feel of other apps, such as using an identical user interface design. 2. Make sure App Store metadata only contains relevant information and content you either own or have permission to use. The metadata provided in App Store Connect is used to populate your app's product page on the App Store. People rely on this metadata to learn about your app and what it has to offer. Leveraging the popularity of another brand or app, either by including irrelevant references or protected content, is misleading and won't help your app succeed. Do: Use engaging, descriptive language to describe your unique app. Create original content that best represents your app, such as screenshots showing the actual app in use. Don't: Don't use protected material you do not have the necessary permission to use, such as app icons that are similar to icons of a popular app. Don’t include irrelevant references, such as popular app names or trademarked terms, in any metadata fields. 3. Provide information that is authentic and verifiable. People want to know the developers behind their favorite apps are who they say they are. It's important to continually review and provide up-to-date information, including the developer or company name listed on your Apple Developer Program account, the Support URL listed on your app's product page, and other helpful information. This will enable your users to contact you when they need help and it will also hinder people who may try to impersonate you, your app, or your service. Do: Make sure all information, resources, and documentation related to your account and apps are current and accurate. Don't: Don’t provide inaccurate information or resources, such as directing people to outdated support pages. Don’t provide fraudulent documentation. Accounts that submit fraudulent documentation will be removed from the Apple Developer Program. Support Incorporating these best practices into your app's development will help you submit apps that follow App Review Guideline 4.1. If you need additional assistance, consider taking advantage of one of the following support options available from App Review: If your submission has been rejected, reply to the message from App Review in App Store Connect and request clarification. Request an App Review Appointment to discuss the results of our review. Appointments are subject to availability, and take place during local business hours in your region on Tuesdays and Thursdays. If you believe your app follows the App Review Guidelines, consider submitting an appeal to the App Review Board. Resources Learn about foundational design principles from Apple designers and the developer community. Learn how to create engaging App Store product pages. Note that apps that violate intellectual property rights are subject to removal through the App Store Content Dispute process. If you believe an app on the App Store violates your intellectual property rights, you can submit a claim.

I have a launch event for my app this Sunday and it was rejected for something that was in the app already. I've been trying to get approved / deployed in the App Store for two weeks now. This is very important to me, most of the issues Apple flags are things that are already on my app just the reviewer didn't seem to catch, such as account deletion button flagged that I have within my settings already. Issues that Apple has flagged seem to be ones that I have already built in and have shared screen recordings showing where they are on the app and it working. I have done the hard work and am patiently waiting for approval onto the app store now. Would love to get this launched by Sunday at the latest! thanks

Hi all, Like others my app submission has been stuck in “waiting for review” for weeks. I know initial app reviews take longer than updates, but this has been delayed far too long and makes me concerned about repeating the process in the future. I submitted this app for review back on Feb 10. It was initially rejected for a minor issue, which I resolved and resubmitted the same day. After that, the build remained in “Waiting for Review” for about two weeks with no further communication. At that point I canceled the submission and resubmitted the build, thinking it may have been stuck in the queue (I now know not to do this next time). Unfortunately the new submission has also been waiting for review for another 9 days now with no messages or updates. I’ve contacted app review support as well (case ID- 102826632729). I understand review times can vary, but delays like this make it difficult for developers to plan launches or push updates when the review process is the only path to distributing apps. As paying members of the Apple Developer Program, we rely heavily on this pipeline functioning reliably. Hoping this post will reach someone from Apple who can help move the process along. If any other devs have suggestions/tips that have worked for them, please share so others in this position can become unblocked. Thanks in advance.

Hi everyone, I submitted my app's first build for external TestFlight testing and it has been sitting in "Waiting for Review" for more than 48 hours. There are no messages in the App Review section and no rejection, the status is simply "Waiting for Review", so it doesn't look blocked, just not picked up yet. A few questions for those who've been through this: For a FIRST external Beta App Review, how long did yours actually take? Is 48h+ normal these days, or is something wrong? Does the first external review really take much longer than later builds? I've read that once your app clears Beta App Review the first time, subsequent builds are approved almost instantly, can anyone confirm from experience? Has contacting App Review support ever actually sped this up for you, or is it just a matter of waiting it out? Any real-world experiences or rough timelines would help me set expectations. Thanks a lot!

I have a launch event for my app this Sunday and it was rejected for something that was in the app already. I’ve been trying to get approved / deployed in the App Store for two weeks now. This is very important to me, most of the issues Apple flags are things that are already on my app just the automated systems didn’t seem to catch such as account deletion button within my settings as the last flagged issue that was already there. Issues that Apple flags I have already built in and have shared screen recordings showing where they are on the app and it working. would love to get this launched by Sunday at the latest! thanks

Hello, we are preparing an app that sells digital subscriptions consumed within the app and we fully understand that Guideline 3.1.1 requires such content to be sold through In-App Purchase. Our question concerns one specific case: In-App Purchase does not appear to be available for App Store accounts in the Russia region. For users in that region, what is the compliant way to offer a digital subscription? Would using an approved local third-party payment provider be acceptable when IAP is not available and if so, are there any conditions or entitlements we should be aware of? For all other regions where IAP is available, we plan to use In-App Purchase as required. Thank you! Kind regards

Hello, Our application connects to our backend server, which only allows access from specific IP addresses for security reasons. We understand that Apple owns the IP range 17.0.0.0/8, but we are unsure whether App Review traffic always originates from this range. Could you please clarify the following? Does App Review always access backend servers from IP addresses within 17.0.0.0/8? If so, is there a more specific IP range that can be allowlisted instead of the entire 17.0.0.0/8 block? If Apple does not provide a dedicated IP range for App Review, what is the recommended best practice for applications that restrict server access by IP address? Our goal is to minimize the allowlisted IP range while ensuring that App Review can successfully access our backend during the review process. Thank you for your guidance.

We are an established Apple Developer with multiple production apps. Over the past four weeks, every submission under our developer account—including both new apps and updates—has either remained in "Waiting for Review" or "In Review" significantly longer than expected. We have already: Contacted Apple Developer Support multiple times Been granted an expedited review Replied to all support cases Despite this, none of our submissions have progressed. I'm unsure if this could be related to an account-level review or another issue affecting our developer account. Has anyone else experienced similar issues? Thank You!

My DSA has been in review since June Digital Services Act 27 Countries or Regions View Jun 1, 2026 In Review How long does this take? I don't understand why it's taking so long. Should we just skip European countries from our apps from now on?

Hey, My app "Machko OTT" (Apple ID: 6778678181, Submission ID: bf9c82cb-52c7-4735-9c94-592ebe38eb76) has been stuck in "Waiting for Review" since July 7 at 4:07 PM, with no update since. Some background: I originally submitted the app for review on June 10 at 5:50 PM. On June 29, I removed it from review, assuming there was a glitch since it was taking far longer than usual. I later re-submitted, but it's now been stuck again with no movement. I also contacted Apple Support directly — they told me I'd get a response within 2 business days. That deadline has now passed with no email reply either. At this point, my app has effectively been pending publication for almost a month. Any guidance on how to escalate this or get an update would be really appreciated. Thanks in advance.

We submitted our banking application, Summit Bank, for review on 8 July. Since then, we have received the notification “Summit Bank Submission (iOS) version 1.3.0 has been approved” on three (3) separate occasions. However, each approval has been followed by the app remaining indefinitely in “In Review,” instead of "Pending Developer Release" forcing us to resubmit the same version repeatedly. Application Details App Name: Summit Bank Apple App ID: 6751147180 Version: 1.3.0 Current Submission ID: dfea3890-a0bf-4136-b5ae-7241db7d15c9 In our most recent submission, we included detailed notes describing this recurring issue and requesting assistance. Unfortunately, despite the app once again being marked as approved, its status has not changed and it remains stuck in the review process. This unresolved issue is causing significant operational disruption, reputational damage, and loss of business, as our customers are unable to access the latest version of the application. We respectfully request that this matter be escalated for immediate investigation and resolution. If there is any issue with our submission or additional action required on our part, please let us know as soon as possible. We would appreciate your urgent assistance in resolving this matter.

I submitted my app nearly a week ago, and it's still stuck on I submitted my app nearly a week ago, and it's still stuck on "Waiting for Review." I also contacted App Review Support, but I haven't received a response. For a service that costs so much, this level of communication is disappointing. I understand that reviews can sometimes take longer, but having no updates or response from support is frustrating. Is anyone else experiencing similar delays? I also contacted App Review Support, but I haven't received a response. For a service that costs so much, this level of communication is disappointing. I understand that reviews can sometimes take longer, but having no updates or response from support is frustrating. Is anyone else experiencing similar delays?

Hello, My name is Tarek Mansour. I've been developing for Apple platforms since before the App Store existed, and my developer account dates back to the year the store launched. I say that only to make one point: I know how this process is supposed to work, and this is not it. My app has been sitting in "Waiting for Review" for over three weeks. It's been on the App Store for more than 10 years with a clean history. The submission in question is a critical bug fix — real users are affected every day it sits there. Every official channel has failed: • Expedited Review Request • Contact Us email • Phone support — hours on hold, no resolution Promised by email more than once that it would be handled — nothing changed Submission ID: 891c1b55-f353-4bf8-bb81-609b1c29a5cc In nearly two decades on this platform I have never seen apps left in the queue for a month with no communication and no working escalation path. Judging by this subtopic, I'm far from the only one. Apple: developers build businesses on the assumption that review is predictable and support is reachable. Right now, neither is true. Please look at this submission — and please address what's happening to the queue generally.

Hello. My app (new iOS app, previously shipped macOS app) has now been waiting in review for 6 days. I submitted it on Wednesday July 8th 2026. Does it normally take this long? Seems pretty long.

So I've got multiple apps on the App Store, one is very complex and another that is more basic. The one that is more basic continually seems to be skipped over in the review process and just sits there in waiting for review (currently been there waiting for a week), while the other gets reviewed within 24 hours. I'm grateful the more complex one clears quickly as I am making several updates each week, but I need the other to clear in a timely manner as well. This is not the first time with this particular app and starting to wonder if there is some issue with the intended audience. I sincerely hope that is not the case. Thank you App Review folks, I know you're swamped, but can you please look into this seemingly repeating issue and let me know why the hold up on this one app I'm particular?

Sign in with Apple works correctly on a physical iPhone in my Capacitor-based app, but fails in the Simulator, and this appears to be causing repeated App Store review rejections. I'm trying to figure out how to get past review.... What happens On a physical iPhone, Sign in with Apple works as expected. In the Simulator, if the user signs into their Apple ID (Settings) and returns to the app, tapping "Sign up with Apple" fails immediately with: The operation couldn't be completed. (com.apple.AuthenticationServices.AuthorizationError error 1000.) (Screenshot attached.) The native Apple sheet never appears — the error returns right away. The actual problem Every time I submit to App Store review, the app gets rejected because Sign in with Apple fails for the reviewer — I believe they're testing in an environment (Simulator, or a device not signed into iCloud) where it returns error 1000. It works on real hardware, so I keep getting stuck in a review loop over something I can't reproduce on device. What I've already checked Sign In with Apple capability is present in Signing & Capabilities for both Debug and Release, and the entitlement is in the built product. The App ID has Sign In with Apple enabled in the Developer portal, and the Services ID / return URLs are configured for Clerk. Resolved an earlier iPad-specific issue where connectedScenes was empty (added a UIApplicationSceneManifest + AppDelegate.window fallback), so ASAuthorizationController now has a valid presentation anchor. Questions Is error 1000 (ASAuthorizationError.unknown) in the Simulator a known environment issue (e.g. no usable Apple ID for the authorization flow) rather than an app bug — given it works on physical devices? For anyone who has been rejected because Sign in with Apple failed in the reviewer's environment: what actually got you through review? Reviewer notes explaining it works on device? Replying in Resolution Center with a screen recording from a real device? Something else? Any guidance appreciated — I'd rather fix the root cause than keep resubmitting.

My app has been in “Waiting for Review” status for 7 days now, which is well beyond the usual turnaround I’ve seen. I haven’t received any communication from App Review, and there’s no message in Resolution Center. I have also raised a ticket but have had no reply. Details: • Submitted: July 7 ‘26 • Type: New app • Status has remained “Waiting for Review” the entire time (not “In Review”) I’ve already confirmed there are no outstanding issues in App Store Connect and no metadata rejections. Has anyone experienced a delay this long recently? Any guidance appreciated.

I have finished a new app that integrates Apple hosted background asset. I have tested and confirm that the assets are downloaded both locally and with a TestFlight build. App review is not able to access the background assets. I can see that the assets are updated with status "accepted". But app review is running into error "A server with the specified hostname could not be found.". These are Apple Hosted Assets. Did I miss any configuration?

Just a mum who made 2 apps to solve a personal problem that I thought would help others. Submitted over a week ago to AppStore Connect. Says "Waiting in Review". Tried to go to apple developer support and ask about the status, but their support page when I hit submit just gives an error. So not sure how I can get a hold of anyone or where to go from here?

I built what Apple would describe as a "reader" app. Because it involves legal and financial information, however, it doesn't qualify as a standard "news" reader, so Apple is not treating as a reader app. That means it needs to have in-app subscriptions. Fine. I think that's a better UI choice for the user anyway. The problem is that the App Store Connect UI for subscriptions and the training materials for Apple's reviewers on subscriptions are horrendous. As my other posts on these forums have documented, they literally do not work. Now with the app in the review process, the reviewers keep sending back rejections because they keep trying to sign up for a subscription with the provided demo account that is already signed up. Why is the demo account already signed up? Because it's a demo account! And that's what Apple wants (to test each and every feature)! Fortunately, there are additional in-app subscription sandbox accounts I've provided credentials for so that from a clean slate, the reviewers can choose a plan and test signing up using those. But they apparently either don't understand that it makes no sense to sign up twice for a subscription or they refuse to do it without explaining why. Instead, they claim that there is some UI problem with the app because it won't let a signed-up account sign up again. This is bonkers. The obvious solution is that if Apple wants each subscription to have a dedicated test sandbox account, then when you add a subscription plan, the credentials for such an account for the reviewers to use should be required fields. But they're not, and now I've wasted two weeks dealing with a feature that technically should not be required for the app at all by Apple's own guidelines. Apple has been less than helpful when trying to sort this out. The entire process is hugely inefficient. If you could just set up a block of 10-20 minutes as an appointment to speak to your reviewer(s) instead of a round-robin that gets you a response once per day at best, it would eliminate probably 80% of the needless back-and-forth that the current process yields.

Hello, I'm evaluating Foundation Models announced at WWDC 2026 and have a question regarding App Store distribution. My understanding is that Foundation Models are only available on supported devices and operating system versions. For apps that rely on Foundation Models as their primary functionality (rather than offering AI as an optional feature), I'm trying to understand the recommended distribution strategy. Currently, iOS provides Required Device Capabilities to prevent users from installing apps that require hardware features such as GPS, ARKit, or NFC. However, I couldn't find an equivalent Required Device Capability for Foundation Models. I also couldn't find a way to limit App Store availability by supported device models. My questions are: What is the recommended way to distribute an app whose primary functionality depends on Foundation Models? Is there currently any supported mechanism to prevent users with unsupported devices from downloading such an app? Is Apple planning to introduce a Required Device Capability (or a similar App Store filtering mechanism) for Foundation Models before public release? Without such a mechanism, users may be able to install the app successfully but then discover that its primary functionality is unavailable on their device. I'd appreciate any guidance on the recommended approach. Thank you.